Computing device and method for wireless remote boot in a networked environment

ABSTRACT

In some embodiments, a secure authenticated remote boot of computing device over a wireless network is performed in a pre-boot execution environment (PXE) using active management technology (AMT) for remote discovery. In these embodiments, a management engine (ME) may maintain full control of a wireless interface and a wireless connection as booting begins. The ME may relinquish control of the wireless interface after a PXE timeout, in response to a shutdown command, or once the device has booted. The ME controls the use of an operating system received from a remote location.

RELATED APPLICATION

This application is a divisional of U.S. application Ser. No.12/623,555, filed Nov. 23, 2009, which is incorporated herein byreference in its entirety.

TECHNICAL FIELD

Some embodiments pertain to wireless devices. Some embodiments pertainto remote boots of computing devices.

BACKGROUND

An operating system may use a variety of sources to boot up in variousenvironments. Networked systems allow a computing device to receivestart up information from a network server. A Basic Input/Output System(BIOS) defines a firmware interface which is the first code run by acomputing device when powered on. The BIOS loads the operating system,identifies, tests and initializes system devices. The BIOS prepares thecomputing device to operate in a known state so that software may beloaded, executed and given control of the device.

The state of a computing device is defined by a system image and is usedby the BIOS. A computer system boots up by executing BIOS instructionsthat cause an operating system loader program to be loaded from a diskdrive into system memory. The BIOS may then cause the computer system toexecute the loader program that, in turn, causes the computer system toload portions of the operating system into the system memory.Subsequently, the operating system may execute one or more program(s) toinitialize and start execution of the operating system.

Many computing devices are wireless devices that include a wirelessadapter card for communicating within a wireless network. Wirelessadapter cards may not have sufficient memory storage to store operatingcode and driver codes used to support wireless networked functionality.Thus what is needed are computing devices and methods that provide forwireless remote boot in a networked environment.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a computer system in accordance with some exampleembodiments.

FIGS. 2-5 illustrate an Active Management Technology (AMT) core hardwarearchitecture resident in a computing device in accordance with someexample embodiments.

FIGS. 6 and 7 illustrate configurations of a computer system inaccordance with some example embodiments.

FIG. 8 is a state diagram illustrating various states of the computersystem in accordance with some example embodiments.

FIG. 9 is a flow diagram illustrating methods for booting a computersystem at power up, in accordance with some example embodiments.

DETAILED DESCRIPTION

The following description and the drawings sufficiently illustratespecific embodiments to enable those skilled in the art to practicethem. Other embodiments may incorporate structural, logical, electrical,process, and other changes. Examples merely typify possible variations.Individual components and functions are optional unless explicitlyrequired, and the sequence of operations may vary. Portions and featuresof some embodiments may be included in, or substituted for, those ofother embodiments. Embodiments set forth in the claims encompass allavailable equivalents of those claims.

The following details some embodiments of a method and apparatus for awireless remote boot, such as an Operating System (OS) streaming method,in a networked environment having access to a wireless network. Inexample embodiments, the method and apparatus utilize existing softwareand firmware instructions (e.g., code), as well as apparatus to retrieveinformation that may be used to enable networked boot up from a wirelessnetwork for a remote computing device. Such techniques may beimplemented without additional memory to the wireless cards thatimplement the wireless connectivity for the computing device, such aswireless-fidelity (Wi-Fi) cards. Existing wireless cards may not havesufficient memory to store operating instructions (e.g., code) anddriver codes to support wireless networked functionality.

Some embodiments leverage the central management functions of a centralserver to provide resources that allow wireless boot up of the computingdevice. By leveraging wireless network support built into a networkedsystem, it is possible to allow a remote boot up from a wireless serverwithout rebuilding the BIOS and other information used at boot up.

In some embodiments, a secure authenticated remote boot of computingdevice over a wireless network is performed in a pre-boot executionenvironment (PXE) using active management technology (AMT) for remotediscovery. In these embodiments, a management engine (ME) may maintainfull control of a wireless interface and a wireless connection asbooting begins. The ME may relinquish control of the wireless interfaceafter a PXE timeout, in response to a shutdown command, or once thedevice has booted. The ME controls the use of an operating systemreceived from a remote location. These embodiments are described in moredetail below. In some embodiments, a host embedded controller interface(HECI) application programming interface (API) is used to communicatewith the ME for communicating over the wireless connection, the HECI APIto serve as a proxy for the wireless interface when managed by the ME.In some embodiments, a universal network driver interface (UNDI) is usedas a host embedded controller interface (HECI) wrapper, the PXE to usethe UNDI to communicate with the ME for communicating network trafficover the wireless connection. In some embodiments, the computing deviceis a wireless communication device configured to communicate inaccordance with an IEEE 802.11 standard. In some embodiments, thecomputing device is a wireless communication device configured tocommunicate in accordance with an IEEE 802.16 standard. In someembodiments, the computing device is a wireless communication deviceconfigured to communicate in accordance with a 3GPP standard forlong-term evolution (LTE).

FIG. 1 illustrates a computer system 100, in accordance with exampleembodiments. The computer system 100 includes access to a wirelessnetwork 122, which may reside within computer system 100 or may beexternal. The computer system 100 also includes a local area network(LAN) 120. A central server 126 may be an enterprise server, a centralserver for implementing control, updates, and other maintenance of oneor more of computing devices 124. The computer system 100 is configuredto implement a remote network boot up for the computing devices 124using resources of the central server 126. Some embodiments implement aPXE, which allows a remote computing device 124, such as a workstation,to boot from a server on a network prior to booting the operating systemon the local hard drive of the computing device 124. The PXE specifies aprocess to load software onto the remote computing device 124 from thecentral server 126. Implementation of the PXE involves supportcomponents in a BIOS and NIC of the computing device 124. The PXEoperates to boot the computing device 124 from the central server 126 bytransferring the boot image file from the central server 126. The PXEworks with the LAN 120 and works with multiple OSs.

FIG. 2 illustrates a computer system 300 having an Active ManagementTechnology (AMT) management mechanism for remote discovery, healing andprotection of computer systems in accordance with some embodiments. Inone embodiment, computer system 300 employs a silicon-resident AMT. TheAMT provides the basis for software designs to address manageabilityissues, improve the efficiency of remote management and asset inventoryfunctionality in third-party management software, safeguardfunctionality of agents from operating-system (OS) failure, power loss,and intentional or inadvertent client removal. The AMT allows thecomputer system 300 to remotely discover computing assets in multipleoperational states. The computer system 300 stores hardware assetinformation, such as in FLASH memory, which may be read out even whenthe computer system 300 is powered off or has an inoperable OS. The AMTmay also provide a general-purpose, non-volatile data store that acceptslocal or network-based storage commands to work with management orenterprise applications.

Furthermore, the AMT may remotely heal computing assets so as to providea proactive alert notification of a system problem, even in situationswhere the computer system 300 is powered off. The AMT providesOut-Of-Band (00B) access to remotely diagnose, control, and repair thecomputer system 300 after software, OS, or hardware failures. The AMTinfrastructure may support the creation of setup and configurationinterfaces for management applications, as well as network, security,and storage administration.

The hardware architecture of computer system 300 may be resident infirmware, and may include a processing unit, such a processing unit 302,a graphics and memory controller hub 308, an I/O controller hub 314 anda Local Area Network (LAN) controller 324. The processing unit 302includes software agents 304 and code for an OS 306. The graphics andmemory controller hub 308 includes a micro-controller 310, which storesand controls Management Engine (ME) 311 including firmware to implementvarious services on behalf of management applications. The computersystem 300 further includes a FLASH memory 312, which stores the systemBIOS for computer system 300. The system BIOS includes machine-readablecode used by the ME, and a third-party data store (3PDS) that enablesapplications to store information as needed in non-volatile memory.

The I/O controller hub 314 includes filters 316, sensors 318 and MediumAccess Control (MAC) layer controller 320, which are used to interfacewith I/O ports and control communications with the computer system 300.A LAN controller 324 is communicatively coupled to the I/O controllerhub 314, and includes OOB unit 326 and wired network interface 328.Network interface 328 may be an Ethernet interface although this is nota requirement. A WLAN controller 325 is communicatively coupled to theI/O controller hub 314, and includes OOB unit 330 and wireless networkinterface 332. The computer system 300 includes multiple Double DataRate (DDR) memory units, such as DDR2 322, to transfer data on risingand falling edges of a clock signal. Each DDR2 322 is communicativelycoupled to the graphics and memory controller hub 308.

The AMT functionality further enables management applications to accessclient computers in a variety of states by accessing the radio in awireless Network Interface Card (NIC). The NIC allows the computersystem 300 to access a wireless network, such as wireless network 122(FIG. 1).

FIG. 3 illustrates a portion of the computer system 300, including theME 311, which in some embodiments, runs on auxiliary power and isavailable at multiple system power states. The ME 311 communicates withME peripherals 440, LAN, Direct Memory Access (DMA) and MAC controller430, and wireless interfaces 420. Physical layer interface 450 may becoupled with DMA and MAC controller 430. The ME peripherals may includea cryptographic engine, Non-Volatile Memory (NVM), and interfaces tovarious busses, such as a System-Management Bus (SMBus) or a SerialPeripheral Interface Bus (SPI) bus. As illustrated, the ME peripherals440 communicates with FLASH memory 312 via a Serial Peripheral Interface(SPI) communication bus. The SPI communication bus allows multiplemasters to share a single FLASH device, including use of the informationstored in the FLASH memory 312, including the BIOS code, firmware, 3PDS,and so forth.

A specified amount of main memory 460 may be dedicated to execute MEcode and store ME run-time data, such as in a manner similar to aUnified Memory Architecture (UMA), which allows a graphics processingunit to share a memory system, or other computer memory architectureenabling shared memory. In some embodiments, the ME 311 stores ME codein a compressed form in FLASH memory 312, and therefore may be accessedwithout accessing a hard drive (not shown). In such embodiments, thecomputer system 300 prevents access of the ME memory range by theprocessing unit 302 (FIG. 2), thus adding security to avoid the abilityof malicious software to access the ME code.

The ME 311 can access its dedicated memory space even when the computersystem 300 is in a powered down state. The graphics and memorycontroller hub 308 (FIG. 2) may dynamically switch among various memorypower states to allow ME access to FLASH memory 312. This capabilityallows for low average power since the memory is ‘on’ only when it is tobe used.

As illustrated, ME 311 may also include various firmware and/or softwarefor performing AMT applications 402, administration (ADMIN) services404, core services 406, management services 408, and network services410. ME 311 may also include management engine hardware abstractionlayer 412 and threadX kernel 414.

FIG. 4 illustrates an Active Management Technology (AMT) core hardwarearchitecture resident in a computing device in accordance with exampleembodiments. Communication between the host OS 500 and the ME 311 may beaccomplished by a Host Embedded Controller Interface (HECI). The HECIdefines a bi-directional communication protocol where either the host OS500 or the network server 530 may initiate transactions. In oneembodiment, the network server 530 implements AMT firmware to initiatetransactions. In some embodiments, transactions may be completedasynchronously by the firmware, such as AMT firmware, and thensynchronized later.

The ME 311 may employ an external memory, such a memory storage deviceor system having a UMA type memory architecture. The external UMA memory523 includes a main memory dedicated to execute ME code for ME 311 andto store ME run-time data for ME 311. The use of the external UMA memory523 may be similar to UMA memories employed in graphics applications. Insome examples, the external UMA memory 523 may include or be locatedadjacent to a graphics UMA memory space. In this way, the external UMAmemory 523 may include an ME memory space and a graphics memory space.From the perspective of the host OS 500, the graphics memory space mayappear slightly larger than the ME memory space.

The host OS 500 may include AMT firmware defined by an AMT serverapplication 502, an AMT client application 504, and a routingapplication 506. A protocol engine 508 controls communications and AMTprocessing, while a TCP/IP unit 510 controls Transmission ControlProtocol (TCP) and Internet Protocol (IP) handling of communications.TCP operates at a high level and provides ordered delivery of datapackets and information from source to destination. IP is used topackage datagrams or packets from source to destination forcommunication in a packet-switched network. The suite of protocols forInternet use is referred to as TCP/IP. The protocol engine 508 may bedesigned to handle multiple protocols, such as Simple Object AccessProtocol (SOAP), HyperText Transfer Protocol (HTTP) and Transparent LANservice (TLS). The SOAP protocol is a specification for exchangingstructured information to implement web services. SOAP may rely onapplication layer protocols for process-to-process communications, suchas Remote Procedure Call (RPC) or HTTP, for message negotiation andtransmission. TLS is a service linking networks, such as remote Ethernetnetworks. TLS allows the connected networks to be viewed as onecontiguous network from the user perspective.

Additionally, the host OS 500 includes a host HECI driver 514 as well asa LAN driver 512 and LAN hardware 516. The host HECI driver 514 providesan interface for the HECI interface or HECI bus that allows the host OS500 to communicate directly with the ME 311. The bi-directional,variable data rate bus enables communication of system managementinformation and events. The bus may be implemented with four wires, arequest and grant pair along with a serial transmit and receive datapair. The LAN driver 512 and LAN hardware 516 provide an interface forthe host OS 500 and the ME 311.

FIG. 4 further illustrates the ME 311 as including an AMT application518, a protocol engine 520, a host HECI driver 522, and a LAN driver524. The host HECI driver 522 operates in a complementary manner to thehost HECI driver 514, communicating over the HECI interface bus. The LANdriver 524 communicates with the LAN hardware 516 through a serial linksuch as an M-link.

The host OS 500 further communicates with the network server 530 via aconnection between LAN hardware 516 and LAN hardware 438. The networkserver 530 also includes an AMT server application 432, a protocolengine 434, and a LAN driver 436. The protocol engines 520 and 434 aresimilar to the protocol engine 508, and may provide complementaryfunctions.

Message flow between a first client pair may continue without regard tothe message flow between a separate client pair. Messages may be ofvarious lengths, and may be subject to the limitations of the user'sreceive buffer (rather than limitations of the HECI drivers). The HECIdrivers 514 and 522 may comprise software or firmware drivers, whichbreak messages into packets to support lengthy messages. Flow control iscommunicated by HECI bus messages, and the HECI driver may wait totransmit a message until an associated client has a receive buffer readyto accept the data.

A FLASH memory, such as FLASH memory 312 (FIG. 3), associated with AMTis shared by multiple masters (Host, ME, and LAN). The FLASH memory 312is a non-volatile memory, wherein FLASH refers to the ability toelectrically erase and program large blocks of the memory array at thesame time. The FLASH memory 312 maintains information stored withoutrequiring power. The FLASH protection scheme does not allow any masterto perform a direct write to FLASH, and read/write permissions to eachFLASH region are enforced in hardware. Each master has a grant Overrideregister that can override its descriptor permissions, giving othermasters access to the region they own. A security-override strap is usedduring initial manufacturing and service returns to program (orre-program) the FLASH memory 312.

FIG. 5 illustrates an example of a Network Interface Controller (NIC)600, which may be used in a system employing an AMT architecture. TheNIC 600 implements an interface that is OS-independent. The NIC 600includes an event manager 602, an asset manager 604, a store manager 606and an administration unit 608. The NIC 600 further includes a protocolengine 610, which implements a SOAP-based application programminginterface (API) consistent with a Web Services Description Language(WSDL). The NIC 600 also includes an HTTP unit 612 and a TCP/IP unit614. In some embodiments, each service supported by the NIC 600 isprovided by a distinct WSDL file. Security measures for the networkinterface may include the use of HTTP Digest, such as defined in RequestFor Comments (RFC) 2617, entitled “HTTP Authentication: Basic and DigestAccess Authentication,” by J. Franks et al, dated June 1999, promulgatedby the Internet Engineering Task Force, and authentication byusername/password credentials. The NIC 600 also supports TLS-securedconnections and mutual authentication. The NIC 600 includes an AMTcertificate 616 and an administration unit 608. As illustrated in FIG.5, the NIC 600 interfaces with the central server 126 including a webbrowser application 620 and a management application 622.

FIG. 6 is a block diagram illustrating a network configuration 700including a central server 720 and a computing device 701 having accessto a wireless network. The computing device 701 further includes aprocessor 703 controlling operation of the computing device 701,including to run code, such as firmware or software, resident in the ME708 and resident or received into the BIOS 710. As illustrated, thecomputing device 701 has a firmware portion having a BIOS 710, a PXEmemory, such as PXE Option Read Only Memory (OPROM) 702, a networkinterface 705. The PXE OPROM 702 provides code to enable PXE for thecomputing device. The network interface 705 interacts with the ME 708 ofMemory Controller Hub (MCH) 706.

The network interface in one example is an HECI API. The HECI APIprovides a software interface that is used to communicate to MCH 706including an ME 708 so as to access AMT capabilities. Communicationbetween the local host operating system (OS) and the ME 708 isaccomplished by means of a HECI driver. The HECI function operatesbi-directionally, as either the host OS or AMT firmware can initiatetransactions.

The computing device 701 operationally may boot up from the centralserver 720 or a wireless network. The ME 708 implements AMTfunctionality for the computing device.

According to an example embodiment, when an option is set to enable PXEand the wireless interface is set by the remote IT console to enableAMT, the ME 708 continues to have full control of the WLAN interface andconnection even when the computing device 701 starts booting. The ME 708may relinquish control of the WLAN interface after a PXE timeout or onreceipt of HECI commands to de-initialize or shut down. The commands maybe received from BIOS 710 or PXE OPROM 702. The BIOS 710 or PXE OPROM702 may directly use the network interface 705, such as a HECI API, tocommunicate with the ME 708 to send and receive the network traffic overthe WLAN (not shown in FIG. 6). The network interface 705 will serve asa proxy or virtual interface for the WLAN interface that is managed bythe ME 708. The ME 708 will have full control of the WLAN interface andauthentication exchange until the time the system boots.

In an example embodiment, the network interface is consistent with theHECI protocol, having commands given in Table I in accordance with someexample embodiments. The HECI protocol includes call made to the ME toinitiate AMT actions.

TABLE I HECI Protocol HECI CALL DEFINITION HECI Signals the ME toinitialize the WLAN interface, INITIALIZE based on Wi-Fi profile that ispre-provisioned and take control of the WLAN interface/connection. HECISignals the ME to relinquish control of the WLAN DEINITIALIZEconnection; this is where the wireless LAN connection is transitionedback to the host. HECI OPEN Signals the ME to open the WLAN interface.HECI CLOSE Signals the ME to close the WLAN interface. HECI TX Signalsthe ME to transmit a packet over the WLAN interface. HECI RX Signals theME to call a receive packet handler when a packet is received over theWLAN interface (interrupt driven). HECI POLL This call polls the ME tofind out if a packet has been received over the WLAN interface.

FIG. 7 is a block diagram illustrating a network configuration 800including a central server 820 and a computing device 801 having accessto a wireless network. In one example, the computing device 801 includesa BIOS 810, a PXE OPROM 802, a UNDI (Universal Network Driver Interface)803 and a network interface 804. The UNDI 803 is defined in a PXEspecification, and acts as the HECI wrapper. The BIOS 810 and the PXEOPROM 802 use the UNDI 803 to communicate with the ME 808 in order tosend and receive network traffic over the WLAN (not shown). The networkinterface 805 interacts with the ME 808 of MCH 806. The UNDI 803internally uses the network interface 804, such as defined in Table Itotalk with the ME 808. The UNDI 803 supports the AMT functionality whileproviding flexibility and ease of integration with a variety oftechnologies for implementing the PXE OPROM 802. Table II defines theactions in operation of UNDI 803 in accordance with some exampleembodiments.

TABLE II UNDI Protocol UNDI ACTION DESCRIPTION UNDI STARTUP This is theUNDI API responsible for initializing the contents of the UNDI code anddata segment for proper operation. Information from the PXE structureand the first PXENV_START_UNDI API call is used to complete thisinitialization. The rest of the UNDI APIs will not be available untilthis call has been completed. UNDI CLEANUP The call prepares the networkadapter driver to be unloaded from memory. This call is made just beforeunloading a universal NIC Driver. The rest of the API is not availableafter this call executes. UNDI INITIALIZE This call resets the adapter(i.e., the NIC) and programs it with default parameters. The defaultparameters are those supplied in response to the most recentUNDI_STARTUP call. The application calls PXENV_UNDI_OPEN to logicallyconnect the network adapter to the network. This call is made by anapplication to establish an interface to the network adapter driver.Note: When the PXE code makes this call to initialize the networkadapter, it passes a NULL pointer for the Protocol field in theparameter structure UNDI RESET This call resets and reinitializes thenetwork adapter with the same set ADAPTER of parameters supplied toInitialize Routine. Unlike Initialize, this call opens the adapter; thatis, it connects logically to the network. This routine cannot be used toreplace Initialize or Shutdown calls. UNDI This call resets the networkadapter and leaves it in a safe state for SHUTDOWN another driver toprogram it. Note: The contents of the PXENV_UNDI_STARTUP parameterstructure need to be saved by the universal NIC Driver in casePXENV_UNDI_INITIALIZE is called again. UNDI OPEN This call activates theadapter's network connection and sets the adapter ready to acceptpackets for transmitting and receiving. UNDI CLOSE This call disconnectsthe network adapter from the network. Packets cannot be transmitted orreceived until the network adapter is open again UNDI TRANSMIT This calltransmits a buffer to the network. The media header for the PACKETpacket can be filled by the calling protocol, but it might not be. Thenetwork adapter driver will fill it if required by the values in theparameter block. The packet is buffered for transmission provided thereis an available buffer, and the function returns PXENV_EXIT_SUCCESS. Ifno buffer is available the function returns PXENV_EXIT_FAILURE with astatus code of PXE_UNDI_STATUS_OUT OF_RESOURCE. The number of buffers isimplementation-dependent. An interrupt is generated on completion of thetransmission of one or more packets. A call to PXENV_UNDI_TRANSMIT ispermitted in the context of a transmit complete interrupt UNDI ISR ThisAPI function will be called at different levels of processing theinterrupt. The FuncFlag field in the parameter block indicates theoperation to be performed for the call. This field is filled with thestatus of that operation on return.

FIG. 8 illustrates a state diagram 900 including a method for operatinga computing device having connection to a central server and to awireless network. As illustrated, the computing device powers on andenters the null state 904. On occurrence of various events transitionsthe computing device either to an active state 910 where the devicedownloads software and a system image to boot the computing device or toa passive state 902 where the device downloads software and a systemimage to boot the computing device.

From the null state 904 on an uplink event for the central server on anetworked connection, considered an uplink event, the computing devicetransitions to the active state 910. An uplink event, for example, maybe the detection of a connection to a network, such as an Ethernetnetwork. In this way, when the computing device initially connects tothe network, a connection is detected as an uplink event. Further whilein the null state 904, on an uplink event for the wireless network, thecomputing device transitions to the passive state 902. The uplink eventmay be when the computing device detects the wireless network, or whenthe wireless capability of the computing device is turned on. Otheruplink events may be implemented according to the computing environmentand system configurations.

From the active state 910, on a link down event, the computing devicetransitions back to the null state 904. Further, when authentication tothe central server fails, such as when the central server implements anAMT mechanism and transitions to the passive state 902, the computingdevice may also transition back to the null state 904.

From the passive state 902, on a link down event the computing devicetransitions to the null state 904. When the computing device fails toauthenticate on the wireless network host, the computing device thentransitions to the active state 910.

FIG. 9 is a flowchart illustrating a method 1000 for managing booting upof an operating system in a computing device. The computing devicepowers on 1002 and enters a null mode 1003, which corresponds to apre-boot mode of an operating system for the computing device. Atdecision point 1004 determines if the computing device has a networkconnection, such as an Ethernet connection. For a network connection, onan uplink event 1020, the computing device attempts to authenticate andconnect on a central server. When the computing device authenticates1022 on the Network connection the computing device enters an activemode 1024, else the computing device remains in null mode 1003. In theactive mode 1024, the computing device loads software onto the computingdevice from the central server. The computing device receives the systemimage 1026 from the central server, and uses this information to boot up1014 the computing device.

Returning to decision point 1004, when a network connection is notavailable, the computing device receives an uplink event to the wirelessnetwork, which is referred to as a host server. At decision point 1008,when the computing device authenticates on the wireless network, anuplink event is processed 1006 and the computing device enters a passivemode 1010 in which the device will boot from the wireless network. Thecomputing device receives 1012 system image information from thewireless network, and uses this information to boot 1014 the computingdevice. If the computing device fails to authenticate at decision point1008, the computing device remains in the null mode 1003.

Both embodiments involve the ME 708 (FIG. 6) and 808 (FIG. 8)relinquishing control of a NIC after the computing device has booted.The triggers used by ME 708, 808 to relinquish control to the host OSafter boot include a configurable timeout for the HECI processing orUNDI API triggers (e.g., calls to DEINITIALIZE or SHUTDOWN). When theplatform of the computing device is connected to both a LAN, such as LAN120 shown in FIG. 1, and a WLAN, such as the wireless network 122 alsoshown in FIG. 1, one of the networks will be used for PXE boot. In someembodiments, connection to the LAN and the WLAN is mutually exclusive atthis point. Processing may be based on the Set8021XPXEEnable interfaceused with a wired or a wireless interface.

In an example embodiment, the PXE information stored in the computingdevice, such as PXE OPROM 702 and 802 is used to support AMT and remoteconnections to the wireless network. In one example, API activities areperformed to configure PXE support with AMT implementing a wirelessnetwork. In one example, the computing device issues a call toSet8021XPXEEnable_WLAN. The PXE timeout period is set to a default valueof 120 seconds. The API sets the PXE_WLAN_Config_flag in the AMTfirmware. The computing device then issues a call toGet8021XPXEEnable_WLAN

The host booting procedures transitions according to and may beimplemented using the following code:

If (PXE_WLAN_Config_flag && !(PXE_boot_complete))   {   AMT continues inactive mode until the remote boot is completed.   }PXE boot completes on detection of any of the PXE features of Table III,i.e., HECI trigger, 802.1x/EAP packets, or PXE timeout. In response thecomputing device sets PXE_boot_complete flag in the AMT firmware.

TABLE III PXE Features PXE Algorithm Feature Vulnerability Security 1.HECI API Trigger to ME-> HECI is Make sure AMT goes in HECI DEINIT orUNDI uninstalled passive mode once PXE SHUTDOWN or disabled bootcomplete in host OS image 2. Configurable PXE boot Makes sure AMT goesin timeout -> 120 seconds passive mode after timeout (default value) 3.PXE boot detection acc to Faster timer, Makes sure PXE 2.1 spec(DHCP-PXE AMT goes in passive mode extension or TFTP packet) aftertimeout CB filter alert-> If PXE boot not detected for 30 seconds, AMTin passive mode

In some embodiments, a machine-readable medium is comprised ofinstructions, which when implemented by one or more machines, cause theone or more machines to receive a registration request from a serviceprovider, store a set of information for the service provider in amemory storage unit, and transmit an indication of the service providerto at least one service consumer in the wireless communication network.

Unless specifically stated otherwise, terms such as “processing,”“computing,” “calculating,” “determining,” “displaying,” or the like,may refer to an action and/or process of one or more processing orcomputer systems or similar devices that may manipulate and transformdata represented as physical (e.g., electronic) quantities within aprocessing system's registers and memory into other data similarlyrepresented as physical quantities within the processing system'sregisters or memories, or other such information storage, transmissionor display devices. Furthermore, as used herein, a computing deviceincludes one or more processing elements coupled with computer-readablememory that may be volatile or non-volatile memory or a combinationthereof.

Embodiments may be implemented in one or a combination of hardware,firmware, and software. Embodiments may also be implemented asinstructions stored on a machine-readable medium, which may be read andexecuted by at least one processor to perform the operations describedherein. A machine-readable medium may include any mechanism for storingor transmitting information in a form readable by a machine (e.g., acomputer). A machine-readable medium may include, but is not limited to,FLASH memory, optical disks, Compact Disks-Read Only Memory (CD-ROM),Digital Versatile/Video Disks (DVD), Read Only Memory (ROM), RandomAccess Memory (RAM), Erasable Programmable Read-Only Memory (EPROM),Electrically Erasable Programmable Read-Only Memory (EEPROM), magneticor optical cards, propagation media or other type of machine-readablemedia suitable for storing electronic instructions. For example,embodiments may be downloaded as a computer program, which may betransferred from a remote computer (e.g., a server) to a requestingcomputer (e.g., a client) by way of data signals embodied in a carrierwave or other propagation medium via a communication link (e.g., a modemor network connection).

It should be appreciated that reference throughout this specification to“one embodiment” or “an embodiment” means that a particular feature,structure or characteristic described in connection with the embodimentis included in at least one embodiment. Therefore, it should beappreciated that two or more references to “an embodiment” or “oneembodiment” or “an alternative embodiment” in various portions of thisspecification are not necessarily all referring to the same embodiment.Furthermore, the particular features, structures or characteristics maybe combined as suitable in one or more embodiments.

Similarly, it should be appreciated that in the foregoing description ofembodiments, various features are sometimes grouped together in a singleembodiment, figure, or description thereof for the purpose ofstreamlining the disclosure, in order to aid in the understanding of oneor more of the various inventive aspects. This method of disclosure,however, is not to be interpreted as reflecting an intention that theclaimed subject matter requires more features than are expressly recitedin each claim. Rather, as the following claims reflect, inventiveaspects lie in less than all features of a single foregoing disclosedembodiment. Thus, the claims following the detailed description arehereby expressly incorporated into this detailed description, with eachclaim standing on its own as a separate embodiment of this invention.

Having disclosed embodiments and the best mode, modifications andvariations may be made to the disclosed embodiments while remainingwithin the scope of the embodiments as defined by the following claims.

The Abstract is provided to comply with 37 C.F.R. Section 1.72(b)requiring an abstract that will allow the reader to ascertain the natureand gist of the technical disclosure. It is submitted with theunderstanding that it will not be used to limit or interpret the scopeor meaning of the claims. The following claims are hereby incorporatedinto the detailed description, with each claim standing on its own as aseparate embodiment.

What is claimed is:
 1. An apparatus, comprising: a memory storage deviceto store a first set of computer-readable instructions to load anoperating system on the apparatus; and a Management Engine (ME) tomaintain full control of a wireless interface and a wireless connectionat a beginning of a secure authenticated remote boot of the apparatusover a wireless network in a pre-boot execution environment (PXE) usingactive management technology (AMT) for remote discovery, relinquishcontrol of the wireless interface after a PXE timeout, in response to ashutdown command, or once the device has booted, and control use of anoperating system received from a remote location.
 2. The apparatus ofclaim 1, further comprising a host embedded controller interface (HECI)application programming interface (API) to communicate with the ME forcommunicating over the wireless connection, the HECI API to serve as aproxy for the wireless interface when managed by the ME.
 3. Theapparatus of claim 1, further comprising a universal network driverinterface (UNDI) as a host embedded controller interface (HECI) wrapper,the PXE to use the UNDI to communicate with the ME for communicatingnetwork traffic over the wireless connection.
 4. The apparatus of claim1, wherein the apparatus is configured to communicate wirelessly inaccordance with an IEEE 802.11 standard.
 5. The apparatus of claim 1,wherein the apparatus is configured to communicate wirelessly inaccordance with an IEEE 802.16 standard.
 6. The apparatus of claim 1,wherein the apparatus is configured to communicate wirelessly inaccordance with a 3GPP standard for long-term evolution (LTE).
 7. Themethod of claim 1, wherein the computing device is a wirelesscommunication device configured to communicate in accordance with one ormore of an IEEE 802.11 standard, an IEEE 802.16 standard, and a 3GPPstandard for long-term evolution (LTE).
 8. A system comprising: one ormore antennas to communicate over a wireless network with a remotesystem; a memory to store a first set of computer-readable instructionsfor loading an operating system; and one or more processors to perform asecure authenticated remote boot of the system over the wireless networkin a pre-boot execution environment (PXE) using active managementtechnology (AMT) for remote discovery by executing functionalities of aManagement Engine (ME), the functionalities including maintaining fullcontrol of a wireless interface and a wireless connection at a beginningof a secure authenticated remote boot of the apparatus over a wirelessnetwork in a pre-boot execution environment (PXE) using activemanagement technology (AMT) for remote discovery, relinquishing controlof the wireless interface after a PXE timeout, in response to a shutdowncommand, or once the device has booted, and controlling use of anoperating system received from the remote system.
 9. The system of claim8, wherein the one or more processors are further configured toimplement functionalities of: a host embedded controller interface(HECI) application programming interface (API) to communicate with theME for communicating over the wireless connection, the HECI API to serveas a proxy for the wireless interface when managed by the ME; and auniversal network driver interface (UNDI) as a host embedded controllerinterface (HECI) wrapper, the PXE to use the UNDI to communicate withthe ME for communicating network traffic over the wireless connection.10. The system of claim 8, wherein the system includes a wirelesscommunication device configured to communicate in accordance with anIEEE 802.11 standard.
 11. The system of claim 8, wherein the systemincludes a wireless communication device configured to communicate inaccordance with an IEEE 802.16 standard.
 12. The system of claim 8,wherein the system includes a wireless communication device configuredto communicate in accordance with a 3GPP standard for long-termevolution (LTE).
 13. A non-transitory computer-readable mediumcomprising instructions that, when executed on a computing device, causethe computing device to perform a secure authenticated remote boot ofthe computing device over the wireless network in a pre-boot executionenvironment (PXE) using active management technology (AMT) for remotediscovery by: maintaining full control by a management engine (ME) of awireless interface and a wireless connection as booting begins; andrelinquishing control of the wireless interface by the ME after a PXEtimeout, in response to a shutdown command, or once the device hasbooted, wherein the ME is to control use of an operating system receivedfrom a remote location.
 14. The non-transitory computer-readable mediumof claim 13, further comprising instructions that, when executed on acomputing device, cause the computing device to: use a host embeddedcontroller interface (HECI) application programming interface (API) tocommunicate with the ME for communicating over the wireless connection,the HECI API to serve as a proxy for the wireless interface when managedby the ME; and use a universal network driver interface (UNDI) as a hostembedded controller interface (HECI) wrapper, the PXE to use the UNDI tocommunicate with the ME for communicating network traffic over thewireless connection.